feat(desktop): let the app icon differ between light and dark - #3941

light-sky, baby and periwinkle were cut from the set during apache#3431 review as
near-duplicates of sky, and re-adding them here was an oversight of that
decision rather than a reversal of it. The blue family stays at sky, cyan, ice
and pale-inverted.

Also corrects the ordering note: the list follows the order the icon
discussion used, but is not one-to-one with its numbering now that three
entries are absent, so a number from that thread maps to a tile by id rather
than by position.

Generated-by: Claude Code

A fresh install now uses one icon in both appearances rather than two. The
dark default is still `ink`, but it is offered rather than applied: the dark
slot stays empty until the user turns the split on, and turning it on seeds
that slot with `ink` and moves the picker to it, so they land on a sensible
dark tile already selected instead of on a copy of the light one.

This keeps a default install to a single tile — the same thing an existing
settings file gets — so the only people who see two icons are the ones who
asked for two.

`startupAppIcon` now derives from the default appearance instead of restating
the light/dark pair, since it has to agree with what a fresh install resolves
to and a second copy of that decision is how the two drift apart.

Generated-by: Claude Code

…table

Review of apache#3916 found the change did not do what it says on two counts.

The packaged bundle still pointed at assets/icon.png, so Finder, Launchpad,
the .app/.exe and the installer all kept the old mascot; only the running
process ever saw the new default. Both mac and win icons now name the shipped
default, with a test that fails if DEFAULT_APP_ICON changes without the
packaging config following — the config is read before the workspace is built,
so it cannot import the constant.

The artwork arrived as opaque PNGs with no way to regenerate or audit them,
which is the opposite of the reproducibility the icon discussion adopted them
for. The generator that produced them now ships alongside: the mark is a
handful of stroked polylines defined by constants, so the provenance of the
artwork is the source. `--check` re-renders and compares bytes, and a test
runs it over a sample covering flat fills, angled gradients and stroke
gradients, skipping cleanly where no python3 is on PATH.

Two smaller correctness fixes in the same area:

- Removing a custom icon only ever examined `appearance.appIcon`. An icon used
  only in dark mode was deleted from disk while `appIconDark` kept naming it —
  the dock fell back, but the setting pointed at nothing and the picker had no
  valid selection. Both slots are now checked, and separately, since `updateIf`
  takes a fixed patch and only the slots that actually match may be reset.
- The generic settings channel filtered out `appIcon` but not `appIconDark`,
  so a write could reach the second slot without queueing behind the icon
  seam's import/removal serialization. It names artwork on the same terms and
  is now filtered the same way.

Also pins the upgrade behaviour that review flagged as unclear: a settings file
that recorded a choice keeps it, and one that never recorded a choice takes the
new default. The second is deliberate — it is how a default changes for people
who were shown the old mark rather than choosing it — and is now a test rather
than an accident of normalization.

Generated-by: Claude Code

Two follow-ups from review of apache#3916.

Removing a custom icon held in both slots used two independent conditional
writes. If the second failed after the first committed, the light slot was
already persisted as the default while the dark slot still named deleted
artwork, `applySettings` never ran, and the handler reported `reset_failed`
over a state it had half changed — the persisted and live views disagreeing
with no way back.

`updateIf` now accepts a patch derived from the state its predicate just
accepted, so a caller that must touch several fields but only the ones that
matched can still do it in one queued write. Removal uses that: both slots
move together or neither does. A test proves it by failing the write and
asserting neither slot moved, nothing reached the dock, and the artwork
survives.

The two artwork drift checks also ran nowhere. `scripts/*.test.mjs` are named
explicitly in ci.yml rather than discovered, and `verify-packaged-app-icons`
had never been listed — so a change to the generator, to `DEFAULT_APP_ICON`,
or to the packaging config could go green while the artwork it names no longer
matched. Both now run after Build. Confirmed against the planner that an
artwork-only diff still routes to `code=true`, so a PNG changed on its own
reaches the step that would catch it.

Generated-by: Claude Code

The drift check compared four tiles byte-for-byte and only checked filenames
for the other 34. That does not deliver what the check exists to claim: any of
the unsampled PNGs could be edited byte-wise, or a colourway constant could
change without its artwork being regenerated, and CI would stay green.

The check now covers the whole generated catalogue, and asserts the reported
count matches the number of generated ids so it cannot silently narrow again.

Rendering 38 tiles at 1024px is ~90s of single-threaded signed-distance
evaluation, which is the reason it was a sample in the first place. The work
is per-icon and pure, so the script now renders across all cores: ~16s on an
8-core machine, which is affordable in CI.

Verified it catches both drift modes it is meant to catch — a byte edited in a
previously unsampled PNG, and a colourway constant changed by one hex digit
without regenerating — each turning the suite red.

Generated-by: Claude Code

The subset comment and the module docstring still described the test as
checking "a handful" of tiles because rendering all of them was too slow.
Both stopped being true when the check went exhaustive and the renderer went
parallel, leaving the source contradicting the test beside it.

Generated-by: Claude Code